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1. INTRODUCTION 


In Activity 3 the functional design of the use cases Optimising Network Traffic Flow (ONTF), Quality of 
Environment (QoE) and Smart Destination (SD) has been described and approved by the 
SOCRATES2.0 steering group in October 2018. In Activity 5 this functional design is elaborated in 
more detailed designs. Based on this latter design the pilot is developed and executed. 


This document presents the functional and technical designs of the Socrates?.° use cases ‘Optimising 
Network Traffic Flow’, Quality of Environment’ and ‘Smart Destination’ in the pilot site Copenhagen. It 
is a report on the technical designs and the changes made on the traffic centre, the realization of 
intermediaries, the changes on back offices, the end-user applications, the system integrations tests, 
the operational period and is the final report. 


The technical architecture of the above mentioned Use Cases includes sequence diagrams, user 
stories and interface descriptions. These are elaborated for each cooperation model, based on the 
functional designs as described in Activity 3. 
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2. INTRODUCTION — OPTIMISING NETWORK 
TRAFFIC FLOW & QUALITY OF ENVIRONMENT 


As the use cases ONTF and QoE are linked closely together those use cases are documented in the 
same chapter. 


2.1 Use case description — Optimising Network Traffic Flow & 
Quality of Environment 


Coming from the policy goals to turn Copenhagen into a Carbon Neutral City by 2025, the pilot in 
Copenhagen focuses on a multi-modal interactive traffic management approach including the 
integration of multimodal services. The ultimate challenge for the pilot site is to find an approach 
where interactive traffic management with various data and service providers can indeed improve the 
level of service. 


For ONTF and QoE the goal is to incorporate multiple modalities (cars & cyclists) and optimise the 

traffic flow based on the policy goals of the city of Copenhagen. This means that cycling is a priority 
over car traffic in the city centre. However, the cars are facilitated in the ring around the city centre. 
This is depicted in the different networks as shown in figure 1 and 2: 
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FIGURE 1 - CYCLIST PRIORITY NETWORK COPENHAGEN 
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FIGURE 2- CAR PRIORITY NETWORK COPENHAGEN 


The network is divided in several links. A link is a one-directional connection between two decisions 
points. On a decision point the driver does make a choice about the next link in its route. 


For each link, the relative speed is monitored. When there is too much traffic, the relative speed will 
drop, and finally it will fall due to a traffic jam. By monitoring the relative speed and calculating the 
Level of Service, it is possible to detect the traffic state which can be transformed into a ‘problem 
state’. This is the trigger to start network management activities. 


Quality of Environment 


Next to the car and cycling networks, there are also areas indicated for the Quality of Environment use 
case. See the maps underneath. The areas are based on the locations of the air quality sensors. 
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2.2 Active partners & roles 


FIGURE 5 — ACTIVE PARTNERS AND ROLES IN THE COPENHAGEN ONTF & QOE USE CASE 


Partner Role in use case 


City of Copenhagen Road Authority and data provider 
Technolution Network Monitor & Network Manager 
TomTom Data provider / End user Service provider 


City of Copenhagen (Road authority) 


The road authority for the city of Copenhagen. They are consulted for their strategies and tactics for 
traffic management and they allowed the connection between the Network Monitor and their traffic 
management platform MobiMaestro so that the ViSense cycling data could be used. 


Technolution (Network Monitor and Network Manager) 


Technolution has the lead for the pilot site and facilitates the Network Monitor and the Network 
Manager. 


TomTom (Data provider & End user service provider) 


TomTom acts as both a data provider as well as an end user service provider where they guide their 
users via an app away from the requested avoided road/areas initiated by the Network Manager. 


2.3 Functional overview 
Changes in relation to Activity 3 — functional design 


The table below contains an overview of the changes made during the further development of the Use 
Case in Activity 5, in relation to the Activity 3 functional design. All the things that have not changed 
are not documented in this table. 


























SOLL IST 
Geofence is Air quality is measured through air 
activated/deactivated based on quality sensors and based on that 
(expected) traffic and derived information a geofence is 
from that data a higher activated/deactivated. 
anticipated pollution 

Intermediary City of Copenhagen acts as City of Copenhagen was not an 
intermediary intermediary. Technolution took over 

that role. 
Pre-/post conditions Conditions still apply. 
Sequence diagram See changes in figure 6 
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2.4 Generic description of end user service 


TomTom deployed an Android app where Turn by Turn navigation is incorporated based on their 
navigation engine. Additional features for that app, incorporated because of SOCRATES2.0, are that 
users are asked to avoid a certain road because there is more traffic on that road then is efficient for 
the overall car network which can cause delays. Next to that, car users are asked to avoid a road if 
more cyclist are detected by the bicycle sensors then the predetermined threshold. In that way space 
is given to the cyclist and creates a safer environment. These advices from TomTom to their users are 
based on the requests that the Network Manager sends out. 

The same can happen for the Quality of Environment. Then the end user is asked to avoid an entire 
area. The end user is informed that the advice is based on poor air quality. In both cases TomTom 
provides an alternative route for the end user. 
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FIGURE 6 SCREENSHOTS FROM APP TOMTOM - ONTF & QOE 
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3. INFORMATION ARCHITECTURE — ONTF & 
QOE 


3.1 Data Flow Diagram (Sequence diagram) 


Optimizing Network Traffic Flow | Quality of Environment 


ViSense sensor: 
Number of cyclists 


MobiMaestro (Traffic | i l 
Management Centre TomTom FCD i ^ir Quality Sensors 


Copenhagen) 


Network Monitor 


Network Manager 


DATEX IlI message 
to TomTom 


TomTom interprets 
message and send 
request to end-user 





FIGURE 7 - DATA FLOW DIAGRAM ONTF & QoE 


3.2 Information Architecture 


The information architecture (IA) is an elaboration of the sequence diagram (see 2.1). It describes the 
processes and interactions between processes. The processes are functional and general conducted 
by one stakeholder as an internal process. A process receives and collects data, enriches the data 
and produces information as a product. Information is sent via protocols to other processes in the 
architecture. 


Step 1: Import ViSense sensor data into MobiMaestro 


There are eighteen ViSense sensors in Copenhagen which count cyclists. The data of six of them are 
used for ONTF. These six have been selected as they intersect on the car and cyclist network. The 
sensor data is imported in the traffic management platform MobiMaestro of the traffic management 
centre of Copenhagen. 


Step 2a: Send trigger to Network Monitor that number of cyclists has exceeded threshold 


MobiMaestro has been configured that per sensor a threshold has been set what an acceptable 
number of cyclists is before it becomes too busy. If the number of cyclists is above the threshold a 
trigger is sent to the Network Monitor. 
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Step 2b: Network Monitor imports FCD from TomTom 
The Network Monitor imports the FCD from TomTom for the Copenhagen network. 
Step 2c: Import air quality data by the Network Monitor 


The University of Aarhus makes air quality data available based on two air quality sensors installed in 
Copenhagen. That data is imported by the Network Monitor. 


Step 3: Network Monitor transfers the data to the Network Manager 
The Network Monitor gathers all the relevant data and sends it through to the Network Manager 
Step 4: Network Manager produces a problem state and acts on it 


Based on the input of the Network Monitor the Network Manager calculates the Level of Service (LoS) 
for each defined link in the network. The Level of Service is a value which provides insights in the 
traffic situation on that specific link from free flow to a severe traffic jam. Taken the LoS into account 
the Network Manager acts if the LoS goes below the predefined threshold. Then it looks which 
measures can be applied to improve the traffic situation, taken not only into account the traffic 
situation on that specific link, but also the traffic situation on the other links that the measure has an 
effect on. The measures are available in the toolbox. In the toolbox the available measures are 
recorded and the toolbox is used as an input for the Network Manager. The measures are based on 
the Network Vision document of the city of Copenhagen. 


If the predefined threshold for number of cyclists at a certain sensor is reached then this is taken into 
account by the Network Manager and will send out a TMex (DATEX II) message to TomTom to avoid 
that specific link. 


The same as above holds for the air quality sensors, the only difference is that then a message is sent 
to TomTom for a specific area and not a link. 


Step 5: Network Manager sends a DATEX II message to TomTom 


When the Network Manager has decided which measure(s) to take then it sends a DATEX II (TMex) 
message to TomTom which specifies which links or areas to avoid. 


Step 6: TomTom interprets message and send request to end-user 


TomTom interprets the message and decides if it incorporates the service request, if so, it adds the 
condition to the specified link/area. It then sends a message to their users in their app with the reason 
to avoid a certain part of the city and offers them an alternative route for this. It is up to the end user if 
they accept this alternative route or not. 
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4. SYSTEM ARCHITECTURE — ONTF & QOE 


4.1 System overview 


(Data) Providers Network Mgr Service Provider / TMC 








data 


sources 
TomTom 


ViSense TMC 


sensors Copenhagen 


Air 
quality 
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Socrates interface Internal interface 


FIGURE 8 - SYSTEM OVERVIEW ONTF & QOE 


4.2 Interfaces 


This section contains detailed information about the interfaces and the information exchanged via 
these interfaces. 


1a. Data sources to TomTom 


This is a proprietary interface from Data source to Data provider, used internally by the Data provider. 
It is not described here. 


1b.ViSense sensor data to MobiMaestro 


ViSense offers an HTTP API to which MobiMaestro of the traffic management center of Copenhagen 
connects to. The data is sent real time and the format of the data is JSON and MobiMaestro 
processes it. 


1c. Air quality data to Network Monitor 


An API has been set up to extract the data from the air quality sensor and makes the data available in 
JSON format. The air quality data is updated every hour. 


2a. TomTom to Network Monitor 


Intermediate Service using Google Protocol Buffers (Protobuf). The API is available using HTTP GET 
and data format is defined in a Protobuf format. The following information is shared via this interface 
with OpenLR location referencing: 


e Average speed 
e Confidence 
e Relative speed 
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e Travel Time 


2b. MobiMaestro to Network Monitor 


A DVM-Exchange connection has been set up between MobiMaestro Copenhagen and the Network 
Monitor. A DVM-Exchange request is sent when the threshold of cyclists has been exceeded. This is a 


real time connection. 


3. Network Monitor & Network Manager 


Internal connection, both within the same system at Technolution. 


4. Network Manager to TomTom 


DATEX II (TMex) message 
Message: 

Protocol: 

Frequency: 

Related TMex dataset: 


Service Request 
DATEX II 
Whenever necessary 


TMPlan exchange 





Message information 

















Name Type Definition 

id String Service request ID 
situationRecordCreationTime String Start of the situation 
overallStartTime String Start time of the service request 
overallEndTime String End time of the service request 





causeType 


Classificatio | The cause the service request is sent 
n out: The following causes can be given: 
- abnormalTraffic, poorEnvironment, 
vulnerableRoadUsers 





openLrLinearAsBinary 


OpenLR OpenLR string of stretch of road used 
for abnormalTraffic and 
vulnerableRoadUsers (ONTF) 





openLrAreaAsBinary 


OpenLR OpenLR string of area used for 
poorEnvironment (QoE) 





pe 





roadOrCarriagewayOrLaneManagementTy | String Action required by receiver: 


doNotUseSpecifiedLanesOrCarriagew 
ays 














5. TomTom to app 


This is a proprietary interface within TomTom. 
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5. INTRODUCTION - SMART DESTINATION 


5.1 Use case description 


The purpose is to support traffic before and after events in Parken Stadium (soccer matches) in order 
to optimize the experience of visitors while maintaining a high level of traffic safety and environmental 
responsibility. 

The infrastructure around the stadium has hardly any room for parking and even dropping people off 
at the stadium is a challenge which often creates a traffic gridlock. This has an effect on the traffic on 
the roads leading to the stadium. Therefore, the city of Copenhagen would like to motivate people to 
take a different modality than a car to the stadium and the people that need to cross that part of city to 
take a different route which does not lead them through the Parken Stadium area. 
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FIGURE 9 - PARKEN STADIUM 


5.2 Active partners and roles 


Two Socrates2° partners and one associated partner are active in the Smart Destination use case in 
Copenhagen. 


FIGURE 10. ACTIVE PARTNERS AND ROLES IN THE COPENHAGEN SMART DESTINATION USE CASE 


Partner Role in use case 


BrandMKRS End user service provider 
City of Copenhagen Road Authority — Event liaison 
(associated partner) 

Technolution Network Manager 
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BrandMKRS (End user service provider) 


The BrandMKRS Smart Destination service in Copenhagen aims at providing a routing advice to event 
visitors in the stadium area. First step is to target and approach users on social media, have them ‘opt- 
in’ to register for the service, and provide them with relevant information. Then, at the day of the event, 
provide the user a route to the area conform the routing request of the network manager. 


City of Copenhagen (Road Authority / Event liaison) 


The city of Copenhagen holds the role of road authority and the way it is set up now as a sort of event 
liaison. The city advises on the events that are planned and if there are special plans/circumstances 
for the event. 


Technolution (Network Manager) 


Technolution, within this use case, has the lead to interact with the city about the events. Furthermore, 
they are responsible that Network Manager sends the right messages at the right time to the service 
provider in accordance with the city. 


5.3 Functional design 
Changes in relation to Activity 3 — functional design 


The table below contains an overview of the changes made during the further development of the Use 
Case in Activity 5, in relation to the Activity 3 functional design. All the things that have not changed 
are not documented in this table. 

















SOLL IST 
Roles No changes in required roles. 
Intermediary City of Copenhagen acts as City of Copenhagen was not an 
intermediary intermediary. Technolution took over 
that role. 
Actors BrandMKRS is end user service 
provider 
Pre-/post conditions Due to the Corona crisis no events 


with a larger group of visitors/ greater 
audience take place since 03/2020 till 
at least the spring of 2021. 


Thus, targeting/ recruiting/ 
interviewing real end users was not 
feasible. A real piloting period could 
not be executed. Compensation via 
friendly user tests. 














Sequence diagram See changes in figure 10 
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5.4 Generic Description of end user service 


To keep traffic flowing as much as possible around events, people are encouraged to use public 
transport. Of course, there always will be people that use cars to get to the event. However, there is 
only limited room for cars around the event location (Parken Stadium) and this will cause traffic. To 
help guide visitors of events that take public transport or their car to the event BrandMKRS offers their 
service. 


BrandMKRS offers a service where they reach out to users via social media (such as Twitter, 
Facebook, Instagram, Snapchat, TikTok) or online media (such as Google Maps, Google Search, 
websites with ads) or social messaging applications (such as WhatsApp, Facetime or SMS). User 
recruitment is done via online campaigns that may include geofences to target audiences based on 
specific locations. People should register as 'SOCRATES user' which entails that BrandMKRS can 
communicate with them via the agreed channels. The information campaign typically follows a 
communication strategy (at what time, what message, to what user group) but messages can also be 
sent real time. In general, BrandMKRS distinguishes between pre-trip, on-trip and post-trip 
communication. 


In the SOCRATES pilot Copenhagen, due to the absence of real events no user community was 
formed. So, no messages were sent out via the different channels (social or online media or 
messaging apps) to real users. During the functional chain test, of the 'Copenhagen Traffic 
Management Centre’ messages were sent (via DVM-X) real time by the BrandMKRS Copenhagen 
service to test users via WhatsApp or SMS. The nature of the messages could differ between: 
modality ("please use public transport"), parking ("if you go by car, then best parking is", Kiss-Ride 
("preferred drop-off / pick-up locations"). 


The first message based on this service is sent to the end user 24 hours before the event takes place 
to give the visitors enough time to prepare or change their travel plans. The second message is sent 
eight hours before the event and then respectively three hours before the event, one and a half hour 
and the last one is at the end of the event. The closer one is to the start of the event the more specific 
the information gets. The timing and the content of the message can easily be altered and is 
something that needs to evaluated once it is used at actual events. 


An example of parking advice is shown on the next page: 


Screenshots of end user service BrandMKRS 


Hi there, strong advice to take 
public transport. By car, go to these 
parking areas and take the metro to 
Vibenshus Runddel St. 

Safe journey!! 


FIGURE 13 - SCREENSHOT MODALITY 
ADVICE + PARKING LOCATION VIA 
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FIGURE 14 - SCREENSHOT WHOLE ROUTE METRO 
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6. INFORMATION ARCHITECTURE — SMART 
DESTINATION 


6.1 Data Flow Diagram (Sequence diagram) 


The events where the city of Copenhagen expects a lot of people who do not visit the event location 
regularly and would like to deploy the service of BrandMKRS, are being communicated with 
Technolution and they are manually inserted into the Network Manager. The message that the end- 
users will get is dependent on how they registered for the service. If they registered as an event visitor 
or someone who lives or works close to the event location. 


Smart Destination 


Events Network Manager 


DVM-X message to 
BrandMKRS 





BrandMKRS: 
Message via social 
media to end user 


FIGURE 15 - DATA FLOW DIAGRAM SMART DESTINATION 


6.2 Information Architecture 


The information architecture (IA) is an elaboration of the sequence diagram (see 2.1). It describes the 
processes and interactions between processes. The processes are functional and general conducted 
by one stakeholder as an internal process. A process receives and collects data, enriches the data 
and produces information as a product. Information is sent via protocols to other processes in the 
architecture. 


Step 1: Insert events into Network Manager 


The events that are going to take place need to be manually inserted into the Network Manager 
including the time and date of the event. 


Step 2: Send message from Network Manager to BrandMKRS 


In the Network Manager there is a calendar function which automatically sends out messages to 
BrandMKRS based on the pre-defined script. In the script the times and dates are documented. The 
messages are sent out via the DVM-Exchange protocol. Technolution and BrandMKRS created a pre- 
defined service-table with all possible DVM-Exchange messages before an event, so BrandMKRS 
was aware of the DVM-Exchange messages’ meaning and how to inform their end users. 
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Step 3: Send message from BrandMKRS to end user 


BrandMKRS will sent out their pre-defined messages to their registered users via social media almost 
immediately after they receive the message from the Network Manager. 


7. SYSTEM ARCHITECTURE - SMART 
DESTINATION 


7.1 System overview 


(Data) Providers Network Mgr Service Provider / TMC 















© Social 
media 





BrandMKRS 








City of 
Copenhagen 
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Socrates interface Internal interface Manual action 





FIGURE 16 - SYSTEM OVERVIEW SMART DESTINATION 


7.2 Interfaces 


Events 


The events are shared by the city of Copenhagen with Technolution and are manually inserted in the 
graphical interface of the Network Manager. 


Network Manager & BrandMKRS 


An DVM-Exchange connection has been set up between the Network Manager and BrandMKRS. A 
DVM-Exchange request is sent when the (time-based) trigger is activated in the Network Manager. 
The information in the message itself is limited to a pre-defined code part of the service-table that was 
agreed on between Technolution and BrandMKRS so that is known what is meant with the message. 
This is a real time connection. 


BrandMKRS & Social media 


BrandMKRS sends a message via social media to their users. The user can choose via which platform 
they want to receive the information. 
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8. OPERATIONAL PERIOD 
8.1 Impact of COVID-19 


COVID-19 had a severe impact on the functional piloting of the services developed to test the use 
cases. 


For the ONTF and QoE use case, traffic was nowhere near normal intensities. This resulted in far less 
congestion and pollution than before the Corona period. This, in turn, diminished the cause for 
necessity of alternative routes, since the preferred routes of users were not affected by congestion 
and users could take those routes free-flow. This led to far less enthusiasm for the recruitment of end 
users for this use case than anticipated. 


For the Smart Destination use case, the impact was even worse, since no events were organised, 
leaving the use case with no practical circumstances to test the benefits for event public. 


Nevertheless, the organisational and technical set-up and execution of all use cases were tested and 
could be evaluated. This was also the case for the functional evaluation of the ONTF and QoE use 
case. Additionally, a technical chain test for the Smart Destination use case was also executed. 
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